• Navigating to the User page (e.g., from dashboard): Two visually distinct loading skeletons appear in sequence — a simpler card skeleton (~130ms), then a more detailed profile skeleton (~700ms) — before the actual content renders.

• Refreshing the User page directly: Only one skeleton (the detailed profile skeleton) appears, then content renders.

• The component renders immediately with isLoading: true

• It manually returns <UserPageSkeleton /> during loading

• When the fetch completes, it re-renders with actual data

• loading.tsx = "the framework manages loading via Suspense boundaries"

• useQuery + manual isLoading check = "the component manages its own loading state"

typescript
// BEFORE:
import { useUser } from '@/queries/useUser';

export function UserPage({ userId }: UserPageProps) {
  const { data: user, isLoading, error } = useUser();

  if (isLoading) {
    return <UserPageSkeleton />;
  }

  if (error) {
    throw error;
  }
  // ...
}

// AFTER:
import { useUserSuspense } from '@/queries/useUser';

export function UserPage({ userId }: UserPageProps) {
  const { data: user } = useUserSuspense();
  // No isLoading check needed — Suspense handles it
  // No error check needed — useSuspenseQuery throws to error boundary

  if (!user) {
    return (/* user not found UI */);
  }
  // ... rest of the render
}

• During navigation, when UserPage mounts, the query suspends → React shows the same loading.tsx fallback that was already showing for the chunk load. The user sees ONE continuous skeleton.

• During refresh, the query suspends on first render → loading.tsx shows ONE skeleton.

• Both paths now show the same single skeleton.

typescript
import { HydrationBoundary, dehydrate } from '@tanstack/react-query';
import { getQueryClient } from '@/providers/getQueryClient';
import { UserPage } from '@/components/pages/UserPage';

interface PageProps {
  params: Promise<{ id: string }>;
}

export default async function Page({ params }: PageProps) {
  const { id } = await params;
  const queryClient = getQueryClient();

  // Prefetch on the server — starts immediately with the RSC request
  await queryClient.prefetchQuery({
    queryKey: ['user'],
    queryFn: async () => {
      // Direct server-side data fetch (no /api roundtrip needed)
      const { getUser } = await import('@/lib/data');
      return getUser();
    },
  });

  return (
    <HydrationBoundary state={dehydrate(queryClient)}>
      <UserPage userId={id} />
    </HydrationBoundary>
  );
}

1. Screenshots at 8829ms vs 9063ms — Two visually distinct skeletons confirmed on screen during navigation

2. React render commit 135 (8.89s) — RenderSuspended trigger: "React.lazy component initialized" → loading.tsx shown (skeleton #1)

3. React render commit 136 (9.02s) — SuspenseResumed, UserPage mounts, renders UserPageSkeleton due to isLoading: true (skeleton #2)

4. React render commit 137 (9.72s) — StoreRerender from TanStack Query → data arrives, profile renders

5. Network timeline — /api/user fetch starts at 9172ms, 500ms after navigation click, confirming client-side waterfall

6. Source code — UserPage uses useUser() (standard useQuery) not useUserSuspense(), despite useUserSuspense being defined and available

7. Pattern comparison — OrderPage and ProductPage have the same useQuery + manual isLoading pattern but do NOT have loading.tsx files, so they only show one skeleton. The user/[id] route is the only one with both mechanisms.

1. OrderPage and ProductPage have the same anti-pattern (just less visible). They use useQuery + manual loading when they could use useSuspenseQuery + route-level loading.tsx for a more consistent architecture. The same waterfall exists for those routes — the API fetch only starts after the component mounts.

2. The useUser() query key ['user'] doesn't include userId. This means all user pages share the same cache entry regardless of which user ID is in the URL. The userId prop is passed to UserPage but never used in the query. This is likely a separate bug.

3. No server-side prefetching anywhere in the app. The getQueryClient.ts already has dehydrate configuration including shouldDehydrateQuery for pending queries, suggesting prefetching was planned but never implemented.

4. The loading.tsx skeleton and UserPageSkeleton show different layouts. Even after fixing the double-skeleton issue, you should decide which skeleton design you want and consolidate. If using the Suspense approach, only loading.tsx matters.